home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
kermit.columbia.edu
/
kermit.columbia.edu.tar
/
kermit.columbia.edu
/
newsgroups
/
misc.19941221-19950208
/
000294_news@columbia.edu_Fri Jan 27 14:38:51 1995.msg
< prev
next >
Wrap
Internet Message Format
|
1995-07-31
|
3KB
Received: from apakabar.cc.columbia.edu by watsun.cc.columbia.edu with SMTP id AA10318
(5.65c+CU/IDA-1.4.4/HLK for <kermit.misc@watsun.cc.columbia.edu>); Fri, 27 Jan 1995 09:38:59 -0500
Received: by apakabar.cc.columbia.edu id AA00667
(5.65c+CU/IDA-1.4.4/HLK for kermit.misc@watsun); Fri, 27 Jan 1995 09:38:57 -0500
Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
Newsgroups: comp.protocols.kermit.misc
Subject: Re: File Transfers Fail Uploading but not Downloading!
Date: 27 Jan 1995 14:38:51 GMT
Organization: Columbia University
Lines: 46
Message-Id: <3gb0hr$ki@apakabar.cc.columbia.edu>
References: <D31EGK.Mo3@physics.purdue.edu>
Nntp-Posting-Host: watsun.cc.columbia.edu
Apparently-To: kermit.misc@watsun.cc.columbia.edu
In article <D31EGK.Mo3@physics.purdue.edu>,
Andrew J. Korty <korty@london.physics.purdue.edu> wrote:
>The problem is this: I can download beautifully (9K packets at 1850
>CPS on a 19200 device with no harware compression), but when I try to
>upload, I can only send a few packets. When the file is small (under
>about 3 packets), I get amazing transfer rates, as high as 7500 CPS!!!
>
>I'm using C-Kermit for OS/2 on my PC and C-Kermit on the remote host
>also. I've tried this with MS-Kermit on this end under both DOS and
>OS/2 (with MS-Kermit the problem is even worse; can send absolutely no
>more than one packet), and I've tried uploading to different remote
>machines with different C-Kermit edits. Therefore, I think the
>problem must be my DOV (data-over-voice) unit. If you're not familiar
>with these, they are Hayes compatible modems that allow you to connect
>and talk on the phone at the same time. It's a direct connection to
>the remote dialup server.
>
Data connections are rarely symmetrical. The fact that something works
in one direction is not a good predictor of success in the other
direction.
Yours are the classic symptoms of big buffers in the downstream direction,
tiny buffers in the upstream direction. A common configuration, based on
the assumption that when one makes a dialup connection, the only upstream
traffic will be keystrokes (at most, 10 per second), but the downstream
traffic will be voluminous (the responses to your commands).
Where are these "buffers"? Probably in the terminal server. And in your
case maybe we also have something going on with the modems. Maybe your
DOV modems allocate higher bandwidth upstream than down.
To cope with this situation, you can sometimes reconfigure the
communications equipment to be more symmetrical. This requires digging
through the technical manuals for the devices involved.
But in any case, it is ESSENTIAL to institute the most effective possible
means of flow control at EVERY juncture along the communication path:
between your PC and the modem, between the answering modem and the
terminal server, and so on. This should be "hardware" (RTS/CTS) flow
control if it is available. In-band "software" flow control methods such
as Xon/Xoff do not work nearly as well. Unfortunately RTS/CTS is not
always available. For example, one popular terminal server model supports
RTS/CTS only in one direction (the downloading one, on the aforementioned
assumption) so uploads through these devices often run into trouble.
- Frank